home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
mospf
/
mospf-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
4KB
|
108 lines
This is only a rough draft - Megan 04/20/92
MOSPF WG meeting, Monday afternoon March 16, 1992
Steve Deering - Chair
Keven Rowett - Notetaker
Agenda
IETF audio multicast experiment
John Moy - implementation experiences of MOSPF
Inter-domain multicast routing
internet draft to proposed RFC?
Deering described the efforts to provide audio of various
IETF sessions to people unable to attend.
The equipment used is a Sun workstation, taking advantage of the
Sparc built-in 79C30 codec. IP multicasting is being used to relay
audio via IP tunneling around routers which don't support IP
multicast routing. Destinations include Hawaii, Australia,
Sweden, and the U.K.
Steve noted that the package provides for talk-back from the distant
participants, but locally they have been unable to interconnect with
audio PA system. (Subsequently demonstrated at the Thursday Plenary).
John Moy's experiences with implementing MOSPF.
Suggested changes as a result of implementing:
1) only one wildcard bit in router-LSA.
0 0 0 0 wildcard VL ASBR ABR
Only one wildcard option was ever really needed.
2) Remove IGMP enable/disable switch:
DL unicast -> IGMP off
MC fwd off -> IGMP off
Else IGMP on.
IGMP switch doesn't provide any new information.
3) No more one directional links in OSPF (LSinfinity
loses meaning in router-LSA).
This is actually a subject of OSPF WG, but wants
both groups in synch.
Eliminates disparity between UNICAST and Multicast routing
tables.
Scott Brim questioned if OSPF can force IGMP off,
especially if BGP is also present.
Multicast forwarding models
John proposed a mixture of the BSD and MOSPF models (see illustrations
in accompanying viewgraphs). The proposed scheme could result in
duplicate packets to multi-homed hosts.
For packets originated in local machine, a check is required to see if
local netowrk looped back the packet. i.e. a LAN (or LAN interface) that
does forward originated packets. This forces MOSPF forwarding decision
to check source address does not equal the local address. TTL value is
one less after MOSPF hop (seems reasonable).
John's plans for document re-organization:
1) more on initialization of DIJKSTRA SPF algorithm.
2) multicast portion of DIJKSTRA algorithm not optional;
everyone must do identical DIJKSTRA for consistent tie-breaking.
3) add an appendix with tie-breaking examples, just to make sure
everyone gets this part right.
MOPSF implementation notes:
John noted that the hardest part of his MOSPF implementation was keeping
the unicast and multicast DIJKSTRA algorithm in synch. Multicast routing
table starts with the unicast table. If the unicast table is not right,
then multicast won't ever be. Must tie multicast forwarding cache
maintenance to unicast routing tables changes.
John asked if IGMP queries should be done over point-to-point links?
Steve suggest that yes, they should be done on p-to-p links because,
for example, the link might be to a host or to a non-MOSPF router.
John also suggested that it might be possible to do multipath multicast
routing by using more creative tie-breaking during tree construction.
The idea is intriguing, but needs more thought. Could possibly use a
hash of the source address, or the (source, destination) pair, to select
among multiple route choices.
John estimated that his implementation took him the equivalent of
30 full-time working days to complete; it added 20% to the size of the
OSPF code.
It was agreed that, after John makes his final pass through the MOSPF draft,
we would submit for publication as an Proposed Standard RFC.
The agenda topic on inter-domain multicasting was not addresses, due to
time limitations and lack of enthusiasm. (We have gone over that
territory at every previous meeting.)